Would be interesting to discuss multi-QR standards (there are many, Fedi currently uses qrloop afaik)

This would actually be very helpful. I've noticed some differences in the Cashu apps that impact scanning interoperability. For example, a QR code generated in Cashu.me can't be scanned by Minibits because Minibits doesn't support animated QRs. I'm assuming the reason has to do with the size of the QR codes. I've seen eNuts be unable to display some tokens in QR form due to their size. Do you know if Fedi has adopted QR Loop for the same reason?

If this seems to be a common need among ecash wallets due to token size, then maybe we should make a note of this in the design best practices section. I don't think we should go as far as recommending the use of animated QRs, but perhaps just include a note explaining that some wallets are using different QR standards like QR Loop to display ecash tokens due to their string size. We could add something like: "If you encounter issues with displaying ecash in QR forms, consider implementing different QR standards such as QR Loop.

I’ve been thinking about this, and I think it’s an important implementation detail with a big impact on the UX. Here are a few UX implications that come to mind:

• When a wallet uses a non-animated QR format (like eNuts), some tokens can’t be displayed as a QR code because they’re too large.
• Animated QR codes require the user to hold their phone up to the screen for longer, and introduce variables like display size and speed settings.

I’m wondering if this falls outside the scope of the guide? Typically designers are at the mercy of whichever QR standard the developers implement, and the UX of QR codes doesn’t vary much. What do you guys think? Is this something we should include? If we did,I think it would make sense to include in the general ecash design best practices. WDYT? @GBKS @mouxdesign @rabbitholiness @yashrajd?

Should be a custom JPG image (different from the banner) with 1200x630px size.

Thanks! I updated this with a unique image. On what part of the site is this image referenced? I would like to see a preview of it if i can.

Surprised to see a mention of solo mints, since the previous pages made strong points about Fedimint being federated, and that Cashu was presented as the solo option...

Can the configurations in bold be links for more info?

Yes, Solomints are something I recently learned that Fedimint supports. They were created as an alternative to Cashu mints. In the first review call with the Fedimint developers, they referred to it as 'using a hammer to kill a fly,' since Fedimint is primarily designed for federated mints. However, in theory, you could use it for a solo mint if you wanted to, as the protocol does support it.

On the intro page, I mentioned that the illustration about connectivity using lighting felt out of place. It seems to fit well with this part about gateways. Isn't the gateway stuff generally a thing and maybe should not be in the fedimint page?

‘Gateway’ is a term used only for Fedimint. It’s unique because it’s a separate service that a federation needs to set up in order to be lightning compatible. Cashu doesn’t use ‘gateway.’ To connect a lightning node on Cashu the user simply edits a mint setup file and plugs in some mint info, like an admin macaroon and TLS cert (at least for LND—other implementations may require different details). Since gateways aren’t relevant for Cashu, I didn’t include them in the introduction.

I agree that this illustration is great for visualizing the role of the gateway. I’ll modify it to show only Fedimint federations so it’s clearer that it’s a Fedimint-specific service enabling lightning and connecting federations to the lightning network.

I don't understand this diagram. There's a lot going on and I can't really tell what each actor does. I don't think the arrows are enough. One solution could be to have numbers in circles on there, along with a legend or text explanation that references them. Or, break it down into multiple diagrams.

I agree. I’d like to revisit the illustrations. I think it would be clearer to depict where each mint or federation is its own circle, and these federations are part of a larger circle representing the Fedimint protocol. The protocol circle would then be connected to the entire bitcoin network with dotted lines representing lightning or on-chain. I’m drawing inspiration from these examples.

I think the table of contents should include individual user flows like "Joining a mint", "Sending ecash", etc.

Do you have a guide or example on how to customize the table of contents and link it to specific sections? It seems to automatically display whatever is marked as ## or H2, but I’d like to create my own shortcuts.

I think it would be helpful to provide some context on what's on this page and what isn't. For example, I was expecting sending and receiving (essential activities), but there is almost no mention of that. That can be totally fine if it's pretty much the same as what we have in the lightning wallet reference design. But I think it might be good to prime people before they dig in.

How about a note that Ecash is super new and UX is still evolving as the tech is maturing? And ask people to contribute, etc?

I want to include something more explicit that mentions the sending practices are the same as those in the existing reference wallet design. Guidelines like entering an amount, displaying fees, and showing a success message still apply. However the key difference is that ecash wallets allow users to generate a payment in the form of an ecash token, which can be shared as a QR code or a string of text. It might be enough to mention this in the text, though I could include an image of a QR code with its text string underneath to show an example. But this image is already shown in the pending tokens section right below.

I would start this page at the point where the user encounters a mint for the first time, maybe during onboarding. That first impression/interaction will be the layup for everything that happens afterwards. You could speak to how onboarding discusses mints, risks, etc. We need to teach both the end user and the reader step-by-step.

When I see a fully populated federation list screen right off the bat, I instantly have a lot of questions. How did I get here? What is a federation? Do most users have multiple mints? For what use cases?

For mint/federation display, you can also speak to the relationship the user has to them. Those are the custodians that hold your money. You have to trust them, and you want full transparency from them. They are also a bit like accounts that you may want to balance. With that in mind it's easier to derive design guidelines.

What is the "Pubkey" field. Does not seem like something a casual user can make sense of.

A version number is also only helpful to highly technical users. Contact info seems more relevant.

Pubkey is not yet used, but it’s in the spec so it needs to be removed. Initially when I included the metadata fields for both Fedimint and Cashu I wanted to provide UI examples showing all the metadata fields the protocol supports. Buit as you pointed out, not all metadata fields are equally important. Some are crucial while some are only relevant to technical users. I will revisit this section and mention this distinction. I’ll focus on UI examples that display the most relevant metadata fields for design, and then include a paragraph about the other fields.
I'll note that while they may be useful for technical users, they are likely irrelevant for most users. It’s best to carefully consider whether or not to include these fields based on your product’s target audience.

There could also be a small notification icon on the home screen.

Seems only useful for highly technical people. Can some of those be actions I can perform? Can I do a "Token state check" if that mint supports that feature?

Yes, token state check is an action users can perform if the mint supports it. It’s quite useful because it allows you to quickly update your token status list without having to re-check each individual token. In eNuts this feature is called ‘check proofs.’ P2PK and multimint payments are also unique actions but no wallet supports multimint payments yet. To your point, listing all of this is probably not useful for most regular users so I’ll remove it.

Does Cashu not have that feature? Might be good to explain that.

Since cashu is a single mint there is no real status it is either up and working or not, where as a fedimint could have a minatory of guardians down ans still work in a degraded state.

Cashu does have a message of the day so it could publish a message thats its lightning node is temporarily down so minting and melting is not possible but you can still swap and funds are safe but there isnt a specific spec for this and it would just be a general message so don't think I would include that here

How about showing something about vetted gateways at the point they become relevant to users? I do think people care, but it doesn't have to be front-loaded or too in-your-face.

I'll have to find out at what point they become relevant to users. I can't think of one. @elsirion any thoughts?

I don't think we should use secrets here. The user does not receive secrets from the mint as the user is the once that generates the secrets as stated in the paragraph before, point 2.

To me the other wording implied it was one signature across all the blinded messages where it is one for each.

Thanks! Just updated.

For point 3. What do you think about:

**3. Token receipt** - The user receives a set of proofs that correspond to specific amounts of bitcoin. These proofs can be combined to create an ecash token of any amount denominated in bitcoin.

I'm not sure about the labeling of this step. "Token receipt". I don't think the user receives a token in this process. Is it correct to say they receive a set of proofs?

Notes from offline discussion: The distinction between federated, federated-single-guardian, and solo mints is an implementation detail. The user should make sure they have vetted the federation, should be able to view important metrics such as historical uptime, total lifespan, and recommendations/reviews from other users. Details such as the number of guardians are easily gamed.

Nit: "federation's operations"

Notes from offline discussion: The graphic here could convey so much more information. I'd include the following:

• A gateway that serves multiple federations
• A gateway that serves a single federation
• A gateway with a lightning channel directly connected to another gateway
• A federation that is served by multiple gateways

We should also differentiate between real lightning channels and gateway<->federation connections

I would get rid of "which operates largely off-chain". Maybe instead you could add a paragraph about why gateways are necessary, describing that without them, users could only operate entirely off-chain when transacting with other users within the same federation (through direct ecash swaps).

Nit: "lightning Network" -> "lightning network"

The concept of unvetted gateways is being removed in the LNv2 module. All gateways will be vetted, since although they can be trusted to not steal user funds, they still must be trusted to provide a good user experience by routing quickly and not maliciously locking up funds in-flight. LNv2 won't be used until fedimint v0.6 (at least 3 months out) so it might be fine to just remove this - use your own discretion.

The federation as a whole could be online, degraded, or offline. However, each guardian is either online or offline.

"Last active" doesn't make sense for online guardians. For offline guardians, "last active" could indicate the last time that the client has seen the guardian online.

Updated so "last active" is only visible for offline guardians.

We can probably remove this section

Can we link to the fedimint documentation here?

https://github.com/fedimint/fedimint/blob/master/docs/meta_fields/README.md

Nit: "alter" -> "alert"

Also it would be useful for federations to be able to extend their expiration time (i.e. they're promising to not shut down before a certain date, but not promising that they will definitely shut down at that date. They might tack on more time later)